[RÉGLÉ] Joomla! 3.6.2 et PHP 7

[RobertG]

Bonjour à tous !

Chez mon hébergeur PHPNET, en pack Premium, le site de test de Joomla! avec les données "Blog" tourne parfaitement sous PHP 7.
Par contre, je viens d'essayer de passer de PHP 5.6 à PHP 7 mes sites fontanil.info et joomxtensions.com : j'obtiens une page blanche dans l'administration, et le debogage et le rapport d'erreurs à "développement" ne m'apprennent rien.
Je suis donc allé voir les logs d'erreurs et sous PHP 7, j'ai ceci pour fontanil.info :

[Tue Oct 04 11:18:13 2016] [error] [client xx.xx.xx.xxx] Failed loading /etc/phpnet-php/php7-x86_64/lib/php/extensions/no-debug-non-zts-20151012/ioncube_loader_lin_5.7.so: /etc/phpnet-php/php7-x86_64/lib/php/extensions/no-debug-non-zts-20151012/ioncube_loader_lin_5.7.so: cannot open shared object file: No such file or directory

et pour joomxtensions.com, protégé par AeSecure :

[Tue Oct 04 11:14:48 2016] [error] [client xx.xx.xx.xxx] PHP Warning: Unknown: open_basedir restriction in effect. File(aesecure/logs/error.log) is not within the allowed path(s): (/home:/usr/share/php:/usr/local/lib/ioncube:/var/www:/tmp) in Unknown on line 0, referer: http://www.joomxtensions.com/administrator/
[Tue Oct 04 11:14:48 2016] [error] [client xx.xx.xx.xxx] Failed loading /etc/phpnet-php/php7-x86_64/lib/php/extensions/no-debug-non-zts-20151012/ioncube_loader_lin_5.7.so: /etc/phpnet-php/php7-x86_64/lib/php/extensions/no-debug-non-zts-20151012/ioncube_loader_lin_5.7.so: cannot open shared object file: No such file or directory, referer: http://www.joomxtensions.com/administrator/

Auriez-vous une idée de comment je pourrais déterminer l'extension (ou les extensions) faisant appel à Ioncube ?
Toutes sont a priori à jour.

Merci par avance de votre aide,
Robert

[cavo789]

Re : Joomla! 3.6.2 et PHP 7

Bonjour Robert

Pour ton premier souci, j'avais d'abord l'impression que ioncube n'était pas géré mais cela ne semble pas ça. L'erreur est donc cannot open shared object avec un no such file. Le souci étant de savoir de quel fichier on parle et le message n'en fait pas mention.

Pour le second site, il y a deux soucis à ce que je lis.
1. open_basedir : as-tu mis en place une protection open_basedir ? L'écriture dans le dossier /aesecure/logs a été rendue interdite (bloquée) car ce chemin n'est pas dans la liste des open_basedir. Vu qu'il s'agit seulement d'un log, ce n'est pas très grave, on peut ignorer le message.

2. Ensuite, rebelotte, même erreur qu'au-dessus.

ioncube étant une extension qui permet l'exécution de code crypté; il faudrait que tu te demandes si tu as ce type de composants. A l'époque CBSubs était crypté de la sorte. Cela te parle-t-il ?

[RobertG]

Re : Joomla! 3.6.2 et PHP 7

Merci Christophe,

Il me suffit de passer de PHP 5.6 à 7 pour faire apparaître ces erreurs, et je ne vois pas, dans les extensions utilisées, quelles peuvent être celles en cause. Je viens de vérifier le dossier aesecure/logs du deuxième site, il est en 755 et il n'y a pas de raison pour que ces droits changent en passant en PHP 7.
Je n'utilise pas de programme dans ces deux sites qui requière Ioncube, à ma connaissance.
Sur le même serveur, certains sites fonctionnent bien en PHP 7, mais je n'ai pas réussi à trouver ce qui fait que certains ne supportent pas cette version... Il n'y a pas de restriction openbase_dir activée dans les paramètres de serveur de ces différents sites.
Je poserai la question à l'hébergeur, au cas où il disposerait d'autres logs.

[cavo789]

Re : Joomla! 3.6.2 et PHP 7

Salut Robert

Je viens de vérifier le dossier aesecure/logs du deuxième site, il est en 755 et il n'y a pas de raison pour que ces droits changent en passant en PHP 7.

open_basedir n'a rien à voir avec le chmod. Est-ce que je dois comprendre que, sous PHP 5.6, tu n'as pas de souci et sous PHP 7 tu as la restriction open_basedir ? Si c'est le cas, c'est donc le fichier php.ini associé à cette version-là qui pose problème et qui définit la restriction.

Il faudrait prendre connaissance du contenu du fichier PHP7/php.ini et voir ce qu'ils ont mis comme valeurs pour open_basedir.

[RobertG]

Re : Joomla! 3.6.2 et PHP 7

Merci Christophe ! Je regarderai ça dans l'après-midi.
Effectivement, je ne fais que changer le version de PHP sans rien toucher d'autre, et dans la définition de PHP, on a dans le même cadre la possibilité pour l'openbase_dir de bloquer le site à son propre répertoire, ce que je n'ai pas fait.

[RobertG]

Re : Joomla! 3.6.2 et PHP 7

Sur un site qui fonctionne, les infos système me donnent une version 7.0.5 en CGI/FastCGI, avec un open_basedir à "no value".

Je viens de regarder les trois fichiers php.ini des dossiers php7, php70 et php71 du serveur : dans aucun n'est défini open_basedir.
Ces dossiers de config php7 et php70 contiennent un dossier conf.d/ioncube.ini avec cette seule ligne

zend_extension = ioncube_loader_lin_5.7.so

le troisième a le même renommé en 00.ioncube.ini et contenant la ligne neutralisée

;zend_extension = ioncube_loader_lin_5.6.so

J'aurais tendance à penser que c'est ioncube_loader_lin_5.7.so qui pose problème.

[cavo789]

Re : Joomla! 3.6.2 et PHP 7

Salut Robert

Je ne peux que me fier à cette ligne "PHP Warning: Unknown: open_basedir restriction in effect. File(aesecure/logs/error.log) is not within the allowed path(s): " qui indique que open_basedir est bel et bien actif. Tu n'aurais pas un php.ini à la racine de ton site ou dans ton /administrator ?

[RobertG]

Re : Joomla! 3.6.2 et PHP 7

Non, il n'y a aucun php.ini autre que ceux de la config des différentes versions de PHP disponibles.
Sur les sites en PHP 5.6 la variable est à "no value", et sur un site qui fonctionne sans erreur sous PHP 7.0.5, elle est définie ainsi :

/home/www/sitesperso/xxxxxxxxxx/:/dev/urandom:/usr/share/php:/tmp/:/home/php-upload/:/usr/local/lib/ioncube

Je n'ai pas testé avec un phpinfo() les sites plantés, mais j'attends une réponse de l'hébergeur.

[RobertG]

Re : Joomla! 3.6.2 et PHP 7

Tu vas jubiler, Christophe !
J'ai en effet une piste, après m'être rendu compte que certains sites récents ne me posaient pas de problème alors que d'anciens plantaient.
En fait, ce sont tous ceux encore protégés par CrawlTrack qui plantent, ce script, ancien maintenant, n'étant probablement pas compatible avec PHP 7 !
Il me reste à confirmer que c'est bien ce script qui est en cause, mais il y a peu de chance que je me trompe.
La voie est libre pour AeSecure, mais je vais regretter Crawltrack qui m'envoyait chaque jour un rapport de visites et attaques des sites protégés...

[cavo789]

Re : Joomla! 3.6.2 et PHP 7

Tu vas jubiler, Christophe !

Ah non du tout...

Les deux scripts CP et CT ne sont plus maintenus depuis maintenant quelques années. Certains utilisateurs ont évoqué le décès de l'auteur sur le forum de ce dernier et personne n'a démenti et, l'auteur ne s'y connecte plus non plus (ce qui serait logique si...).

Pour le rapport des visites, tu as des outils comme Piwik si je ne m'abuse qui fait ça hormis G..gle

Pour le rapport des attaques, depuis le début d'aeSecure, j'ai programmé l'envoi d'un mail de notification lors de certaines attaques. J'ai désactivé cet email dans la v2 parce que, voilà, je pense qu'un outil de sécurisation doit sécuriser et permettre aux gestionnaires de ne pas être importuné.

Qu'un mec s'évertue à attaquer mon site en passant par ici ou par là, à la limite, je m'en moque un peu tant que les attaques sont arrêtées. Le rapport ne pouvant jamais qu'afficher les attaques ayant été contrées, bah, c'est peu important (selon moi) de savoir qu'hier un mec a essayé une URL avec une tentative de SQL injection. Si je veux le savoir, j'ai le log des accès bloqués disponible dans aeSecure et dans la version multi-sites.

Peut-être vais-je réactiver cette notification par email (un mail par attaque) mais ce n'est pas ma priorité.

Bonne journée.

[RobertG]

Re : Joomla! 3.6.2 et PHP 7

Merci Christophe pour ces informations !